This table combines stoichiometric properties with assumed application-rate
scenarios.

• would it make more sense to separate material properties from application-rates?
• See more general requests about dataset documentation in my general review comments. Some specific questions are below
• what columns come from the source, and what information was added during manual curation?
  • e.g. are the Rows* and Trees* application-rate values directly supported by
    the cited sources, or did sources provide more granular, species level rates?
• Why does the build script expose only the Rows* values in
  ca_compost_amendment?
• Is the intended distinction that synthetic N rates are crop-specific, while
  compost/organic amendment rates are only available at a broader crop-structure
  level?
• Given the contents include manure, blood meal, paper, wood chips, straw, and
  other organic materials, would organic_amendments.tsv or
  compost_amendments.tsv be a clearer filename than compost.tsv?

yeh did the split. one table for the properties (ca_organic_amendment_properties, so C:N, total N, 4-week PAN, material_class, source), one for the rates (ca_organic_amendment_app_rate, long by material and crop_structure). they join on material

to your other questions:

what columns come from the source, and what information was added during manual curation?

pretty much all of it's straight off the sheet, except material_class (we set that by hand, more on it below), the g/m2 columns (converted from lbs/acre with ud_convert), and the short citations (we mapped those from the source urls). it's laid out in the readme.

are the Rows* and Trees* application-rate values directly supported by
the cited sources, or did sources provide more granular, species level rates?

sheet has both. for 30 of the 32 it's the same number copied across, but 2 of em (blood meal, fresh poultry manure) really do differ and trees comes in lower. the sources only go down to crop-structure, not species, so that's as fine as it gets.

Why does the build script expose only the Rows* values..
yeh that's flagged, old script dropped Trees. both are in now.

Is the intended distinction that synthetic N rates are crop-specific, while
compost/organic amendment rates are only available at a broader crop-structure
level?

ryt, exactly. the N rates are per crop, but amendment rates only come per crop structure (rows = annual, trees = orchard), so the two tables get keyed differently on purpose

where does m come from? I don't see it in compost.tsv

yeh good catch, that whole function's gone. back when the harmonizing was in the build script, material_to_class() was working out the class on the fly with grepl. m was just the material name getting passed in, but yeh, you'd have to go chase the call to see that, which is the whole problem. now it's a plain column in the source data, one class per material, mapped to CalRecycle list (14 CCR 17852). just data you can read instead of code you have to trace

why are only Rows[MIN|MAX] and not Trees[MIN|MAX] used here? (see also general question about documentation)

not on purpose. same deal as the m thing, when the harmonizing was jammed into the build script it only wired up the Rows columns and quietly dropped Trees. now the harmonize step is separate script on scc and it splits Rows/Trees into the long table by crop_structure, so both stick around. most materials have the same rate either way, but 2 that don't (blood meal, fresh poultry manure) keep their tree rate now instead of losing it

Do crop-names come from a controlled vocabulary? Any reason not to use the LandIQ names here?

Where do PFTs come from? On one hand, row/woody is a simple designation, and there may be reasons to include a grouping in this dataset. But caution should be used and rationale/motivation documented because PFT groupings are opinionated, and in this case alfalfa is not typically considered a 'row' crop (it is forage).

two things here

crop names: yeh those are FREP / UC ANR names off the extension pubs, not LandIQ, and that's on purpose. the rates get published at that level, and some landIQ subclasses (like "miscellaneous deciduous") you can't really pin one rate to. landIQ to FREP mapping lives over in the workflow's Crop_types crosswalk, not in this table

pft: fair, and yeh ryt, alfalfa's forage not row crop. honestly pft_group is just hand set in the spreedsheet, it's a rough row/woody/rice bucket that lines up with grass vs deciduous pfts, not a real botanical/ag call. I kept it matching the canonical cadwr_pfts.csv, which also calls alfalfa row (it's under the pasture class there). I did try pulling pft_group straight from cadwr during harmonize so it'd be one source of truth, but it came out worse, the crosswalk sends oats into the misc grain and hay bucket so it flips to "hay", and about 9 crops don't match cleanly and just drop out. so it stays hand set, and I wrote the reasoning plus the alfalfa caveat into the docs